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Description 

[0001] This invention relates to the transfer ot data be- 
tween database systems. More particularly, the inven- 
tion relates to establishing the context in which data ex- 
changed between databases controlled by dissimilar 
(heterogeneous) relational database management sys- 
tems can be mutually understood and preserved, and 
data conversions minimised. 

[0002] Currently there is great interest in joining to- 
gether a plurality of database systems at different sites 
to form a distributed system which provides any user at 
any site with access to data stored at any other site; see 
for example, AN INTRODUCTION TO DATABASE SYS- 
TEMS, Vol. 1, by C. J. Date (4th Edition, 1986), at pp. 
587-622. Date envisions that each site would constitute 
an entire database system with its own database man- 
agement system (DBMS), terminals, users, storage, 
and CPU. 

[0003] Communications of the Association for Com- 
puting Machinery, vol.33, No.1, January 1990, pages 
70-80, discloses sharing of data between heterogene- 
ous distributed databases using a common data model 
and translation to a common standard query language, 
to overcome problems associated with data duplication 
and the cost of developing equivalent applications in dif- 
ferent languages. 

[0004] In a distributed database system such as the 
type described by Date, the DBMS at any site may op- 
erate on a machine type which is different than the ma- 
chine type of another site. Indeed, there may be as many 
different machine types as sites. For example, Interna- 
tional Business Machines Corporation (IBM) has 
DBMSs which operate on IBM System/370 machines, 
IBM AS/400 machines, and IBM PS/2 machines. 
[0005] The machines upon which the DBMS of a het- 
erogeneous database system run all represent informa- 
tion in different internal formats. For example, numeric 
information on IBM PS/2 machines is stored with the 
bytes in low order to high order sequence. On other ma- 
chines, such information may be stored in high order to 
low order sequence. For floating point information, there 
are IEEE floating point machines and hexadecimal float- 
ing point machines. Character information is processed 
in many different code representations, the choice of 
which reflects historical or cultural roots. 
[0006] As DBMSs grow and evolve over time, they 
may be embodied in a series of versions or releases. 
Each of these may require additional information to be 
exchanged in a distributed database system. When 
these changes are introduced, all sites must be in- 
formed. 

[0007] When a database program is written, compiled 
and executed entirely in one environment (machine and 
DBMS), it rarely is sensitive to the exact representation 
of the data which it processes. The data compiled into 
the program and the data stored in database structures 
are all represented identically so the operations behave 
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as expected. Thus, a COMPARE command executed in 
a single database environment can always be made to 
manipulate data correctly, just by using the high level 
language operations of the system. 

s [0008] Thus, given disparity in machine types and the 
ever-evolving nature of DBMSs. it is inevitable that a dis- 
tributed database system can be heterogeneous in the 
sense that any site may manage a database by means 
of a combination of machine and DBMS which is differ- 

10 ent from the combination at another site. 

[0009] Provision is made in the prior art for solving the 
problems of machine and system incompatibility in a dis- 
tributed, heterogeneous database system. Three solu- 
tions are of interest. 

is [0010] The earliest solution may be termed 'applica- 
tion beware". This solution usually starts as a connec- 
tion between identical database systems which grows 
over time to incorporate some machines which differ 
slightly from the original. In these solutions, there is no 

20 way for the system to automatically handle the differenc- 
es, with the result that the application program was giv- 
en this responsibility. If access to heterogeneous data- 
bases was needed badly enough, the application was 
written to make any necessary accommodations. 

2S [0011] The second solution utilises a canonical repre- 
sentation of data. This approach calls for conversion of 
data into a single, generic (canonical) representation 
before transport from one database site to another. Su- 
perficially, this solves the problem of automating the sys- 

30 tern to handle differences between differing databases. 
However, this approach requires many extra conver- 
sions which are inefficient, and introduces many conver- 
sion errors, making the approach inaccurate. For exam- 
ple, conversion of a floating point number always re- 

35 quires rounding off, with a concomitant loss of accuracy. 
When converting from one to another floating point rep- 
resentation, say, from IEEE to hexadecimal, precision 
is lost. In changing from hexadecimal to IEEE, scale is 
lost. Where character translations are performed, many 

<o of the special characters are lost because of lack of 
equivalence between character codes. In this solution, 
conversion errors which do occur are introduced at a 
point in the process far removed from the application. 
This increases the difficulty of identifying and respond- 

« ing to errors. 

[0012] The last solution employs a gateway conver- 
sion in which a central facility is responsible for matching 
any database representation to any other. Ideally this 
reduces the inefficiency, inaccuracy, and error propen- 

so sity of the canonical representation since conversions 
can be avoided when they aren't needed. However, in- 
ter-site communication is lengthy, slow, and expensive. 
The gateway is a single node to which all inter-site paths 
connect for all interactions. Instead of a request and re- 

55 sponse between the two participating sites, there are 
two requests and two responses for every data transfer. 
When conversions are required, they are still done in a 
part of the distributed system which is remote from the 
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application. 

[0013] Thus, there is an evident need in distributed, 
heterogeneous database systems to support effective 
and accurate exchange of data, while reducing the 
number of conversions, and the communications over- 
head. It is also desirable to perform any needed conver- 
sion at the site where the data to be converted will be 
processed. 

[001 4] The object of the present invention is to provide 
an improved method and apparatus for transferring data 
between heterogeneous data base systems. 
[0015] The invention relates to a system including a 
first database management system for managing a da- 
tabase including data having a first data format and a 
second database management system for managing a 
database including data having a second data format. 
The invention is a method for converting data transmit- 
ted between a first database management system and 
a second database management system, in a system 
including the first database management system for 
managing a database (40) including data having a first 
data format and the second database management sys- 
tem for managing a database (50) including data having 
a second data format, the method including the steps 
of: storing at the first database management system and 
at the second database management system respective 
sets of machine descriptors describing machine data 
formats and system descriptors describing database 
language characteristics; establishing a communication 
link between the first and second database manage- 
ment systems, including each of said first and second 
database management systems sending to the other 
one of said first and second database management sys- 
tems an identifier of its machine and system descriptors, 
each of said identifiers being in a canonical form under- 
standable by both database management systems; 
sending from the first to the second database manage- 
ment system a command containing data in a data for- 
mat native to the first database management system; 
and converting, at the second database management 
system, data in the command sent from the first data- 
base management system utilising the machine de- 
scriptors and system descriptors identified by the first 
database management system. 
[0016] One embodiment of the invention relates to a 
method for establishing the context in which data ex- 
changed between heterogeneous relational DBMSs 
can be mutually understood and preserved, and data 
conversions minimised. Particularly, a sequence of in- 
formation transfer is described which enables a data- 
base to request or receive data expressed in a non-na- 
tive form. Thus, with the practice of this invention, a 
DBMS may receive data in a foreign format and itself 
perform the necessary conversion of the data. 
[0017] In order to minimize the number of conver- 
sions, a method is provided whereby no data is convert- 
ed until it is needed in a specific format for processing. 
This method allows each system to always send all data 



in its preferred (native) format, or the current format of 
the data if the data is just passing through an interme- 
diate system without being processed, when data is re- 
ceived, it is converted to the native format of the system 
s only when it has reached its final destination (is being 
passed to the application, or stored in the database), or 
when it actually needs to be processed by an interme- 
diate system. 

[0018] In this embodiment of the invention, a data- 
10 base in a distributed, heterogeneous database system 
contains predefined descriptions of all machine environ- 
ments in the system (machine descriptors) and prede- 
fined descriptions of database language structures (sys- 
tem descriptors) for each DBMS with which it can par- 
's form data exchange. When a database operation begins 
which requires two heterogeneous databases to con- 
duct an information exchange, a communication link is 
established between them. Next, each DBMS identifies 
its machine and system descriptors to the other. This 
zo establishes a data context and is done only once for the 
life of the communication link. Once established, re- 
quests, responses and data can be sent or received. 
When any data is sent, it is sent in the native format of 
the sender. Specific descriptions of the data precede the 
25 data itself and refer to the machine and system descrip- 
tors earlier identified. When the data is received, infor- 
mation contained in the specific descriptions enable 
these descriptions to be referenced to the machine and 
language descriptors and passed off to a conversion 
30 process in the receiver. Taken together, the specific de- 
scriptions, and the machine and system descriptors 
which they reference, precisely characterise the envi- 
ronment where the data originated and establish, at the 
receiver, a context for accurate conversion of the data 
35 into a format which is native to the machine/system com- 
bination of the receiving site. 

[0019] The invention reduces the total overhead re- 
quired in making and responding to a data request by 
eliminating unnecessary data conversions, thus in- 

40 creasing the speed with which a request for data is serv- 
iced. It also minimises the necessary conversion rou- 
tines needed in each system by requiring conversion on- 
ly INTO a system's native format, and never FROM its 
native format into some other format. 

45 [0020] In order that the invention may be more readily 
understood, an embodiment will now be described with 
reference to the accompanying drawings, in which:- 

FIG. 1 A is an illustration of user data which is to be 
so transferred between non-equivalent database sys- 
tems, 

FIG. 1 B is a top level representation of the relation- 
ships of all descriptors which define the environ- 
55 mental context of the user data illustrated in FIG. 
1A, 

FIGS. 2A, 2B, 2Cand2D illustrate machine descrip- 
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tors, 

FIGS. 3A and 3B iliustrat system descriptors to- 
gether with their references to machine descriptors, 

FIGS. 4A and 4B illustrate user data descriptors of 
the invention with references to machine and sys- 
tem descriptors. 

FIG. 5 illustrates the procedure of an embodiment 
of the invention in the example of command and da- 
ta flows to set up and request a set of user data 
between a requesting and serving machine, 

FIG. 6 illustrates a representative system architec- 
* ture on which an embodiment of the invention may 
be practised, and 

FIG. 7 illustrates the procedure of an embodiment 
of the invention in the example of command and da- 
ta flows between receiving and sending machines 
passing through an intermediate DBMS system. 

Description of the Preferred Embodiment 

[0021] When used herein, the term 'descriptor' 
means a unit of data used to characterise or categorise 
information. The term "data object" is taken to mean a 
data structure element that is necessary for the execu- 
tion of a program and that is named or otherwise spec- 
ified by a program. A 'reference' is a construct such as 
a pointer which designates a declared object. Descrip- 
tors, data objects, and references are all understood in 
the context of a programming language. In relational 
DBMSs, a well-known relational language is SQL. 
[0022] An 'environmental context" is an information 
set which describes the database system which origi- 
nates a block of user data. Data is in "native form" if it 
is made up of data types and control information in a 
form used by the database system which is processing 
it; otherwise, it is "non-native" or foreign". A database 
system "environment" is the set of logical and physical 
resources used to support database management. 
[0023] For relational database systems, the SQL lan- 
guage describes several different data types. These 
types include INTEGER, FLOAT, VARCHAR, and many 
more. Depending on the machine on which an SQL da- 
tabase manager is implemented, the actual bit repre- 
sentations for data values having SQL data types vary. 
For example, the IBM System/370 employs a hexadec- 
imal floating point representation, the IBM AS/400 em- 
ploys the IEEE format, and on IBM OS/2 machines, 
IEEE byte reversed formats are used. These differences 
are implied by the machine environment and are not for- 
mally exposed to application programs executing in the 
environments. 

[0024] Furthermore, there are many SQL identified 
standard control blocks, such as the SQL communica- 



tion area (SQLCA) which is defined in terms of SQL 
types. The SQLCAs in the machine nvironments de- 
fined above are not identical. This invention formalises 
a method and means for exchanging information be- 

5 tween heterogeneous DBMSs about machine charac- 
teristics and DBMS language structures such that little 
or no descriptive information must be exchanged at run- 
time in order to convert data to a native form. Addition- 
ally, when database sites match, even though the data 

io may have been forwarded through intermediate DBMS 
systems which do not match, no conversions are per- 
formed at all, thus preserving completely the integrity of 
the data being exchanged. When these sites do not 
match, data conversions are performed close to the ul- 

is timate point of use where errors introduced by imperfect 
conversions can be dealt with according to the needs of 
the requesting application. 

[0025] This invention is described using simple ma- 
chines, database management systems, and user data. 

20 Those skilled in the art will understand that detailed im- 
plementations will require support for many more gener- 
ic data types than are described hereinbelow, many 
more DBMS information blocks, and user data with 
many more fields. The extensions to handle these cases 

25 are manifest and would only serve to unnecessarily ob- 
scure the invention if presented herein. 
[0026] FIG. 1A illustrates user data in hexadecimal 
format. The data are shown in two forms, 1 0 and 20. 
The user data 10 appears as it would in a typical per- 

30 sonal computer environment. The data 20 has the same 
meaning as the data 1 0 except that it appears in the form 
it would have in a typical mainframe environment. 
[0027] The user data forms illustrated in FIG. 1 A form 
the example upon which explanation of the invention is 

35 based. When the user data is to be sent from the per- 
sonal computer environment to the mainframe environ- 
ment as illustrated by the direction 31 -30, it must be 
changed in form from 10 to 20. Conversely, if the user 
data is to be sent from the mainframe to the personal 

40 computer environment, that is, direction 30-31 , it must 
be changed in form from 20 to 10. 
[0028] The actual data being transferred consists of 
three rows. Each row is an entity containing all of the 
fields necessary to describe the outcome of an SQL 

45 statement. With reference to the rows in each user data, 
the first fields 1 1 and 21 are SQL communication areas 
which describe the outcome of an SQL statement. In this 
regard the SQL statement is assumed to be a command 
in the SQL language which results in the manipulation 

50 of data in a database. In the example, the data affected 
by the outcome of the SQL statement consists of five 
fields. In the first row, the first fields 12 and 22 contain 
the integer value 1 00, the second fields 1 3 and 23 con- 
tain the character value "ABC", the third fields 14 and 

S5 24 contain the integer value 80, the fourth fields 1 5 and 
25 hold the character value "ZYX", and the last fields 1 6 
and 26 contain th floating point value 12.3. 
[0029] The second row of each representation in FIG. 
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1 A consists of an SQL communication area followed by 
the integer value 200, "DEF", the integer value 160, th 
characters "WVU", and the floating point value 45.6. 
Similarly, the third row includes an SQL communication 
area, integer 300, characters "GHI", integer 240, char- 
acters "TSR", and floating point 7S.9. 
[0030] It will be appreciated that the integers in the 
user data 10 are in low to high sequence, and in high to 
low sequence in the user data 20. Characters are coded 
in ASCII in the personal computer user data and in 
EBCDIC in the mainframe user data. Floating point is 
IEEE low to high in fields 16 of the user data and hexa- 
decimal excess-64 in fields 26 of the user data 20. The 
communication areas 11 in the personal computer ma- 
chine use formats which are different than the SQL com- 
rrtunication areas 21 in the mainframe environment. 
[0031] No distinction has yet been made as to which 
direction the data in FIG. 1 A will be transferred. That is, 
no statement has been made as to which environment 
is the server and which the receiver of data. The method 
of this invention is completely symmetric and reversible. 
However, for the purpose of explanation, assume that a 
request for user data is made by a personal computer 
DBMS, that a mainframe DBMS server receives the re- 
quest, obtains the user data locally, and sends the user 
data, which is received by the requesting machine. Re- 
latedly, in FIG. 1A, the requested data is user data 20 
which must be rendered ultimately into the form repre- 
sented by user data 10. The invention provides for es- 
tablishing a context by which the receiver can accept 
user data 20 and prepare for conversion of that data into 
the format represented by user data 10. This invention 
does not concern the actual conversion process itself, 
but rather with a method and means for delaying the 
conversion until the data reaches the location where it 
is to be processed. 

[0032] In FIG. 1 B, there is illustrated a personal com- 
puter machine environment 40 ("receiver") and a main- 
frame machine environment 50 ("server"). The personal 
computer environment can include, for example, the 
IBM PS/2 product programmed with an IBM OS/2 SQL- 
based database management system. For conven- 
ience, the machine name of the personal computer 40 
is indicated by reference numeral 41 . The DBMS which 
runs on the machine 40 utilises a code to represent char- 
acters and control function meanings. For this purpose, 
a code page maps all code points to the graphic char- 
acters and control function meanings utilised by the 
DBMS. The code page is represented by reference 
number 42. The DBMS is a language-based system, 
and in the example, it is assumed that the DBMS is an 
SQL-based system. Further, it is assumed that the ver- 
sion or level of the language is SQLAM3. This is denoted 
by reference numeral 46 in FIG. 1 B. 
[0033] A complete characterisation of the personal 
computer environment which processes user data 10 
therefore must include an indication of the type of ma- 
chine which processes the data, representation of ma- 



chine-level information such as th datatyp s which ex- 
ist in the machine, and information showing in what form 
the data exists in the machine. In the example of FIG. 
1 A, the data types are integers, floating point numbers, 

s and character strings. In the personal computer, inte- 
gers are represented in low to high sequence, charac- 
ters are in ASCII, and floating point is IEEE low to high. 
All of this information is represented in the invention by 
a machine-level representation descriptor. In FIG. 1B, 

io the machine-level representation descriptor for the per- 
sonal computer machine is indicated by reference nu- 
meral 44. 

[0034] The context for conversion also requires infor- 
mation describing characteristics of the language in 
'5 which the DBMS sending the information is written. In 
this description it is assumed that all of the DBMS sites 
are written in one or another version of an SQL-based 
language. In order to accommodate non-identical rep- 
resentations of control information produced by these 
20 varying versions, a system-level language characteris- 
tic descriptor must be available to the converting ma- 
chine in order to convert the language-specific portions 
of the user data. In FIG. 1 A, the language-specific por- 
tions are the communication areas. In order to provide 
zs this system-level information about the language char- 
acteristics, the converting machine is provided a sys- 
tem-level information unit descriptor. In FIG. 1 B, the sys- 
tem-level descriptor for the personal computer language 
environment is indicated by reference numeral 45. 
30 [0035] The context is completed by the provision of 
application level information specific to the user data be- 
ing transferred. This information is given in the form of 
an application level user data descriptor. For the per- 
sonal computer machine environment, this descriptor is 
35 indicated by reference numeral 47. The application level 
descriptor includes a control block for conveying infor- 
mation between cooperating DBMSs. This descriptor is 
in the form of a prefix appended to the user data which 
is sent to the receiver. This prefix contains information 
40 setting forth the machine and system-level characteris- 
tics of the transferred data. The system-level informa- 
tion provides a reference to the system-level information 
in the system-level descriptor corresponding to the lan- 
guage version of the serving system, as well as a refor- 
ms ence to the machine-level information in the machine- 
level descriptor representing the serving machine. In 
FIG. 1B, reference numeral 47a represents the system- 
level reference made in the application level descriptor 
47, while reference numeral 47b indicates the machine- 
so level reference made in the descriptor. As FIG. 1 B illus- 
trates, reference is also made by the system-level de- 
scriptor to the machine-level descriptor. In FIG. 1 B, the 
reference numeral 45a represents the machine-level 
reference made in the descriptor 45. 
55 [0036] It should be evident that a user data context 
can be conveyed in whole each time user data is sent 
to a receiver by appending machine, system, and appli- 
cation level descriptors to the data. Appropriately, this 
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would be employed in an asynchronous communication 
environment. In a synchronous communication environ- 
ment, context could be completely conveyed by transfer 
of machine and system-l vel descriptors initially, fol- 
lowed by transmission of application level descriptors 
and binding of the received application level descriptors 
to the machine and system descriptors at the receiver's 
site. In either case, the machine and system-level de- 
scriptors would have to be transferred, in whole, at least 
once between the sites. This transfer is not required in 
this invention. 

[0037] Thus, in FIG. 1 B, assuming that the mainframe 
machine 50 is sending data, its machine-level and sys- 
tem-level descriptors 54 and 55 must be made available 
to the requesting personal computer machine 40 and 
linked to application level descriptors 57 in order to con- 
vert the user data of FIG. 1 A from the representation 20 
to the representation 10. Relatedly, the descriptors 54, 
55 and 57 must be made available to the machine 40. 
Similarly, for data transferred in the opposite direction, 
that is, from the personal computer machine 40 to the 
mainframe machine 50, the descriptors 44, 45 and 47 
would have to be made available to the mainframe ma- 
chine 50 in order to convert user data 10 into the form 
of user data 20 in FIG. 1 A. 

[0038] In the practice of this invention, it is asserted 
that, during the implementation of each DBMS site 
which participates in a distributed, heterogeneous data- 
base system, a decision is made as to which specific 
machine representations will be supported at the site. It 
is asserted that the "native* representation of the ma- 
chine on which the site's DBMS will run is supported. 
That is, if data from another DBMS identical to the re- 
ceiving site's DBMS is received, the representation is 
"native" and requires no conversion. Additionally, other 
machine types will be supported as partners. Generally, 
the "non-native" representations of data types will be 
converted to "native" ones at the receiving site before 
processing. In the preferred embodiment, at each site, 
there is maintained a list of acceptable machine partner 
types at each site. Thus, at the site of the personal com- 
puter machine 40, a list of acceptable machine types 
includes the machine and code page corresponding to 
identifiers 51 and 52 in the machine 50. The list indexes 
to a set of descriptors which include the machine-level 
and system-level descriptors for all acceptable system 
partners. Thus, if the personal computer machine 40 re- 
ceives simply identification of the machine and lan- 
guage present at the site 50, these identifications can 
be brought to the list which will index to the necessary 
descriptors in the list of descriptors, the indexed descrip- 
tors corresponding to the descriptors 54 and 55. 
[0039] Therefore, when the personal computer 40 
generates a request for data from the DBMS running on 
the machine 50, the receiver machine 40 sends its ma- 
chine and system-level name (PS/2, 437, SQLAM3) to 
the system to which connection is desired, in this case, 
the machine 50. If the machine 50 finds these names 



unacceptable (not in its list) then an error is returned to 
the receiver and the connection is brok n. If the names 
are acceptable to the machine 50, the machine 50 as- 
sumes the status of server and completes connection 
s by sending its machine and system-level names to the 
receiving machine 40. If these names are acceptable to 
the receiver, then the connection is established. Other- 
wise the connection is broken. 

[0040] Having established the connection, the receiv- 
io er sends a data request to the provider/server machine 
50. The provider/server constructs a user data descrip- 
tor 57 according to the characteristics of the data re- 
quested, in this case according to the characteristics of 
user data 20 in FIG. 1A. In this case, the descriptor is 
'5 built to reflect the presence of the SQL communication 
area 21 and the five user data fields 22, 23, 24, 25, and 
26. The provider/server machine 50 then sends the de- 
scriptor 57 and the user data 20 to the receiver machine 
40. 

20 [0041] Upon receipt, the receiver uses the descriptors 
obtained in response to the machine and system-level 
identifier sent by the machine 50 and the references 
contained in the application level descriptor 57 to con- 
vert the user data 20 from the server's representations 

25 to the receiver's representations for subsequent 
processing. 

[0042] It should be appreciated that the identifiers ex- 
changed between the machine and the user data de- 
scriptor must be in a canonical form which is understood 

30 by both systems. In the preferred embodiment, this form 
is defined by a particular code page in EBCDIC. With 
this common basis for understanding, each site in the 
distributed system will recognise the identifiers and user 
data descriptors of any other site. 

35 [0043] Refer now to FIGS. 2A-2D for an understand- 
ing of the structure and contents of machine-level rep- 
resentation descriptors according to the invention. The 
descriptors for four machine types are illustrated. The 
descriptor 60 represents a machine exemplified by an 

•«o IBM PS/2 executing a DBMS which uses code page 437 
for character coding. The descriptor 70 characterises a 
mainframe machine of the IBM System/370 type whose 
DBMS uses code page 037. The descriptor 80 is for an 
IBM AS/400 machine using code page 037. The de- 

« scriptor 90 is for an hypothetical machine called OTHER 
using code page 850 for character encoding. The de- 
scriptors in these figures represent the machines in very 
simplified terms. The representations correspond to ge- 
neric data types which are recognised and used by all 

so database sites in a distributed system. In the figures, the 
data types are INTEGER for integer numbers, FLOAT 
for floating point numbers, and CHARACTER for non- 
numeric information, such as letters of an alphabet. 
Each generic data type is also described in terms of a 

55 format which is particular to the machine whose descrip- 
tor is illustrated. 

[0044] The machine-level descriptors of FIGS. 2A-2D 
are shown as multi-field data objects, with the fields con- 
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taining information relating to a generic data type or a 
data type format. Thus, detailed specifications of the IN- 
TEGER data type are contained in multi-field sections 
62, 72, 82, and 92 of the machine-level descriptors. De- 
tailed specifications of the representation of floating 
point numbers for these machines are contained in sec- 
tions 64, 74, 84. and 94 of the descriptors. Character 
representations specifications are contained in sections 
66, 76, 86, and 96 of the descriptors. 
[0045] In the illustrated descriptors, each generic data 
type is identified initially by a marker definition (MD). For 
integers, the markers are in fields 67, 77, 87, and 97 of 
the descriptors. The markers for each generic type are 
identical in each machine descriptor set. They identify 
unambiguously the generic type of the representation 
Which follows. Each MD is followed a type definition 
(TD). The type definition shows exactly, to the bit, how 
the data is represented in the machine identified by the 
descriptor. Taking integers as an example, the four TDs 
shown have three different bit representations. Two ma- 
chines represent, in fields 88 and 78, that integers are 
binary values with the bytes ordered from high to low 
significance. One machine uses binary values, but re- 
verses the order of the bytes, storing the low order byte 
first, as indicated in field 68 of the descriptor 60. The 
machine represented by the descriptor 90 represents in- 
tegers in decimal digits in a packed format as indicated 
by field 98. The TDs shown are not all the same. How- 
ever, the TDs which are the same mean exactly the 
same thing and are represented in exactly the same way 
among the descriptors. Thus, for example, integer high- 
to-low in fields 78 and 88 of descriptors 70 and 80 is 
exactly one representation. 

[0046] In the invention, the MD-TD pairs can each 
represent a family of types. Integers of length 1, 2, 3, 
4 ... bytes all can share the same descriptor. Similarly, 
for characters the actual code page to be associated 
with the type is a separate parameter. The code page 
specified in the TDs 69, 79, 89, 99 is a default which can 
be overridden. This is explained below with reference to 
FIGS. 3A and 3B. 

[0047] The significance of a TD is not limited to asso- 
ciation with a single generic data type. Thus, the same 
TD may be used as the representation for several dif- 
ferent generic data types or MDs. For example, if there 
were a generic type called WEIGHT, it could be repre- 
sented by floating point or integer numbers. It may be 
the case that different machines would support it differ- 
ently. Such variation is supported fully by this invention. 
Thus, a generic data type is named specifically by the 
MD; how the data type is represented is specified by the 
TD. 

[0048] One additional feature that will be evident to 
the ordinarily skilled practitioner is that the order of the 
generic type specifications (MD-TD pairs) is not impor- 
tant to the significance of the machine-level descriptors. 
The meaning set by the MD is used to establish linkage 
to an appropriate TD from a higher level descriptor, such 



as a system-level descriptor. 

[0049] FIGS. 3A and 3B illustrate the structure and 
contents of system-level descriptors and how those de- 
scriptors are referenced to machine-level descriptors. In 

5 FIGS. 3A and 3B, the system-level descriptors illustrate 
two different levels of language support. In this regard, 
the descriptor 100 of FIG. 3A is for a level called 
SQLAM3 while the descriptor 1 20 of FIG. 3B is for a level 
called SQLAM4. 

io [0050] The system-level descriptor for an SQL infor- 
mation block which includes status of the SQL calls, the 
SQLCA, consists of markers (MDs), grouping descrip- 
tors (GDs), and row descriptors (RDs). Consider now 
the two system-level descriptors 100 and 120. In these 

»5 descriptors, the first markers, 102 and 122, respectively, 
identify groups of fields which are to be included in the 
SQL communication area. These markers give generic 
meaning to the group of fields which follows, and are the 
same at all levels of DBMS implementation. In each de- 

20 scriptor, the group marker is identified as SQLCAGRP. 
[0051] In the system-level descriptors, the group 
markers are followed by grouping descriptors (GD) 104 
and 124, which indicate exactly which fields should be 
included in the SQL communication areas for user data. 

25 [0052] A grouping descriptor has the property that 
members of its described group are ordered but not yet 
arrayed into a linear vector of fields. 
[0053] Another property of grouping descriptors can 
be appreciated with reference to FIG. 3A where the 

30 grouping descriptor 104 includes machine-level refer- 
ences, in this case, lnteger-4 and Character-80. These 
members of the indicated group are references to data 
types identified by marker definitions in machine-level 
descriptors. As FIG. 3A shows, these references pro- 
as vide reference directly to the integer and character MDs 
of the machine-level descriptor 60 (which is identical 
with the descriptor of FIG. 2A). The references are indi- 
cated by bindings 1 1 2 and 1 1 4. In the invention, the val- 
ue specified in a reference is used to override the default 

40 length built into the machine descriptor. Thus, reference 
114 in FIG. 3A overrides the machine length of its re- 
spective integer representation in the machine-level de- 
scriptor 60 to four bytes. In FIG. 3B, references 133 and 
134 also override the machine length to four bytes for 

45 integers. 

[0054] In FIG. 3B, the system-level descriptor 120 de- 
notes one more field in the SQL communication area 
than the previous system-level descriptor 100 for 
SQLAM3. One more value therefore is returned to sta- 

so tus in a CA of user data at this higher level. It is contem- 
plated in the practice of the invention that, during con- 
nection processing, both the requesting and receiving 
DBMS tells the other what to expect. Preferably, the sys- 
tems agree to operate at the same system descriptor 

55 level, and agree to the lower one. 

[0055] The group description, 1 04 in FIG. 3A and 1 24 
in FIG. 3B, is followed by another marker, 106 in FIG. 
3A and 126 in FIG. 3B. These markers indicate that a 
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row description for an SQL communication area is fol- 
lowing. In each case, the row descriptor references the 
group described earlier, 110 in FIG. 3A and 130 in FIG. 
3B. This vectorises all of the fields and completes the 
definition of information which can be exchanged. In this 
row form, the SQL communication area can be ex- 
changed on commands which do not involve user data, 
but which do involve system status information. 
[0056] The row descriptors 1 08 and 1 28 are identical 
in both levels; they refer to groups which contain differ- 
ing information (104 and 124), which, in turn, reference 
different machine descriptors 60 and 70. The row de- 
scriptors therefore make an actual block dependent on 
a language level or version, and make the block specific 
with regard to an identified machine, as well. 
[0057] The system-level descriptor blocks illustrated 
in FIGS. 3A and 3B of either level can map onto any of 
the machine descriptors, independent of the order of the 
descriptors in the machine. The reference is to the MD 
entries in the machine descriptors. The generic type of 
field in the SQL communication area is linked to the rep- 
resentation of that generic type in the machine-level de- 
scriptor. As thus described, a system-level descriptor 
can provide a machine-independent way to specify the 
contents of blocks of information to be exchanged be- 
tween DBMSs. They provide both group descriptions 
(which will be used by higher-level descriptors) and row 
descriptors which describe complete objects which may 
be exchanged. The row descriptors included in the sys- 
tem-level descriptor can be referenced by another row 
descriptor to produce an array. This is illustrated and dis- 
cussed be low with reference to FIG. 4. The system-level 
descriptors are established early in the implementation 
of a DBMS and assembled into a set. The set required 
for any level of implementation can be given a name 
which any other implementation will understand. In this 
regard, the name of the system-level descriptor 100 in 
FIG. 3A is "SQLAM3". In FIG. 3B. the name of the de- 
scriptor 120 is "SQLAM4". In the practice of the inven- 
tion, it is these names alone which are exchanged when 
a communication connection is made, thereby obviating 
the need to exchange the descriptors themselves. 
[0058] Refer now to FIG. 4 for an understanding of the 
structure and content of a user data descriptor and how 
its linkages with machine- and system-level descriptors 
provide a complete context which enables a receiver 
DBMS to understand and convert user data from non- 
native to native form. The user data descriptor 200 pro- 
vides a system-level and machine-level-independent 
way to describe user data. It is contemplated that this 
descriptor would not be built until run time, since, par- 
ticulars of user data are not known until after installation 
of a DBMS and creation and population of the relational 
tables in the DBMS, and until receipt of a particular re- 
quest for data. 

[0059] The user data descriptor 200, like the system- 
and machine-level descriptors discussed previously, 
consists of markers and other descriptors. A first marker 
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MD 211 tags a group 212 consisting of an SQL commu- 
nication area reference 21 3 to the system-level descrip- 
tor 100, and five references 213, 214, 215, 216, and 218 
to the machine-level descriptor 70. Thes six references 

5 correspond to the six fields which make up a respective 
row of user data 20, which is reproduced for conven- 
ience in FIG. 4B. Thus, the group 21 2 identifies the fields 
within a row of the user data, field by field, tells what 
generic type of data is in each field, and specifies the 

io size of the data. For example, the group 212 has a first 
reference SQLCAGRP-0 which indicates that the first 
field in a row of user data will consist of an SQL com- 
munication area. As shown in FIG. 4B, a communication 
area "CA" is in the first field 21 of each row of the user 

>* data 20. Similarly, the second field, field 22, in a user 
data row is a two-byte integer, the third field, field 23 is 
a three-byte character, the fourth field, field 24 is a two- 
byte integer, the fifth field, field 25 is a three-byte char- 
acter, while the last field, field 26 is a four-byte floating 

20 point number. 

[0060] The six references, 213, 214, 215, 216, 218, 
and 220 result in a group with seven fields, two from the 
system-level descriptor (lnteger-4 and Character-80) 
and five from the user data. All of these references are 
independent of a particular language level and a specific 
machine. It is true that the described data is very much 
dependent on these descriptive levels, but the key of 
this invention is that the description of the data is not. 
[0061] Returning to the explanation of the user data 

30 descriptor 200 in FIG. 4A, the next MD marker 224 tags 
a RD row descriptor with a reference 226 to the marker 
211. This relerence is used to define a row of elements 
in the row of user data. As explained above, such a row 
would include seven fields, the two fields of the SQL 

35 communication area followed by the five user data 
fields, in order. This completely enumerates the fields 
for one object which can be exchanged between heter- 
ogeneous DBMSs. It includes information in the com- 
munication area as to the status related to the request 

40 which fetched the data, along with the data. MD 224 is 
followed by an RD 232 with a modifier "1", which indi- 
cates that one copy of each element of the defined group 
should be included in the final row. 
[0062] The final MD 228 tags an RD 234 with a refer- 

45 ence 230 to the row descriptor 232. This descriptor is 
used to make an array or table of the set of rows com- 
prising the user data 20 of FIG. 4B. The modifier '0' in 
the RD 234 indicates that the referenced row should be 
repeated as many times as necessary to include all the 

so data which follows. This is of significant importance in 
queries since it is seldom possible to predict the final 
number of rows in an answer set before sending the first 
one (and the user data descriptor) to the receiver. 
[0063] In summary, the user data descriptor provides 

55 a mode of describing data which is independent of the 
system-level and machine-level artifacts in the de- 
scribed data. The data described includes DBMS status 
information and the user data proper. The user data de- 
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scriptor thus accommodates the definition of any data 
which a user can retrieve from (or send to) a DBMS. 
When the user data descriptor is bound to both a sys- 
tem-level descriptor and a machine-level descriptor, ac- 
tual data can be understood in physical terms. Thus, the 
references (bindings) to the machine-level descriptor 70 
and system-level descriptor 100 give physical meaning 
to the referencing members of the group 212 It is as- 
serted that these references can be implemented con- 
ventionally by standard binding techniques. 
[0064] FIG. 5 illustrates a procedure for establishing 
a conversion context bs'mg the data objects whose 
structures and functions have been described above. 
The procedure includes generic commands for request- 
ing and completing a communication connection and for 
requesting and providing data. The procedure of FIG. 5 
is illustrated as a simplified sequence which shows only 
the parameters which must, of necessity, be exchanged 
for transferring data between requesting and serving 
machines and establishing the translation context in the 
receiving machine for conversion of the data. It is reit- 
erated that the procedure of the invention is not con- 
cerned with how data is corrected but rather where dat- 
ed is converted. Particularly the invention enables the 
receiver of the data to convert the data for establishing 
particular values for those parameters. 
[0065] The structure of FIG. 5 places all of the re- 
questing machine actions in the left-hand side of the 
drawing and all of the serving machine actions in the 
right-hand side. Thus, in step 240 a user at the request- 
ing machine first issues a request for data which is main- 
tained by a DBMS in the serving machine. Next, in step 
252 the requesting machine executes a REQUEST- 
CONNECTION command sequence directed to the 
serving machine. The REQUEST-CONNECTION se- 
quence includes parameters to identify the requesting 
machine, its character code, and its language level. In 
the example, the requesting machine is identified as a 
DBMS executing on a PS/2 personal computer, utilising 
a specific code page (437) for character coding, and op- 
erating at a specific DBMS language level (SQLAM3). 
The parameters in the HEQUEST-CONNECTION step 
are no more than identifiers. Next, in step 254 the serv- 
ing machine receives the connection request, validates 
the machine- and system-level identifiers, and uses 
these identifications to index to machine- and system- 
level descriptors. Assuming that the serving machine 
recognises and possesses the machine- and system- 
level descriptors identified in the connection request, it 
executes a COMPLETE -CONNECTION in step 256 in- 
cluding parameters which provide machine- and sys- 
tem-level identification to the requesting machine. In 
step 258, the COMPLETE-CONNECTION response re- 
ceived from the serving machine is validated in the re- 
questing machine and the identifiers are used to index 
the appropriate the machine- and system-level descrip- 
tors. For example, in the example of FIG. 5, the request- 
ing machine would index to the machine and system de- 



scriptors 70 and 100 illustrat d in FIG. 2B, 3B, and 4A. 
Next, in step 260, the requesting machine assembles a 
data request and sends it in step 26. 1 as a REQUEST- 
DATA command to the serving machine. This 

5 REQUEST_DATA optionally includes an input data de- 
scriptor (built in step 260) with optional input data, if ap- 
propriate for the SQL to be executed. In step 265, the 
serving machine receives the REQUEST-DATA com- 
mand, including optional input data and descriptor. If in- 
to put data is present, a conversion process is called in 
step 267. The serving machine responds to the 
REQUEST_DATA command in step 269 by obtaining 
the requested user data and building a user data de- 
scriptor such as the descriptor 200 illustrated in FIG. 4A, 

»5 and executes a PROVIDE-DATA command in step 270 
by sending the user-data descriptor and the user data 
as, for example, the first row in the user data 20 in FIGS. 
1 B and 4B. The requesting machine then, in step 272, 
receives the transmitted descriptor and user data and 

20 calls a conversion process to convert the data. Accord- 
ing to the needs of a particular implementation, the bind- 
ings between the user data descriptor and the indexed 
machine and system descriptors can be done in step 
272 or left forthe called conversion process. In step 274, 

25 a second REQUEST-DATAcommand is sent, its param- 
eters are processed, with the server, in step 276, obtain- 
ing and returning the requested user data with another 
PROVI DE_DATA command (step 278). The requesting 
machine again, in step 279, processes the data accord- 

30 ing to the user data descriptor received with the first 
PROVI DE_DATA command, and to the system level, 
machine type, and code page values received during 
the connection portion of the process. Now if the receiv- 
er requires more data, it issues another REQUEST-DA- 

3S TA command, with the server returning the data with an- 
other PROVIDE-DATA command, and soon. 
[0066] An architecture for implementing the proce- 
dure of FIG. 5 is illustrated in FIG. 6. In FIG. 6, the re- 
questing machine is assumed to be, as set out above, 

to an IBM PS/2 personal computer, while the server is as- 
sumed to be a mainframe of an IBM System/370 type. 
The requester is identified by reference numeral 280, 
the server by 282. It is asserted that the requester 280 
is conventionally structured with a CPU, storage, a com- 

45 munications adapter for communicating with the serving 
machine 282, and a user interface for receiving com- 
mands from and providing responses to a user. In the 
storage resides an application program 300, a relational 
DBMS of the SQL type which includes an SQL applica- 

so tion manager 306 and a communications agent 310. In 
addition, two dictionaries, 342 and 346, are stored which 
include machine descriptors (dictionary 342) and sys- 
tem-level descriptors (dictionary 346). 
[0067] The serving machine 282 can comprise a con- 

55 ventionally-programmed IBM System/370 mainframe 
computer with an SQL-type DBMS 334. An SQL appli- 
cation manager 318 interfaces a communication agent 
314 with the DBMS 334. Two dictionaries 322 and 326 
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are provided for storing system-level descriptors (dic- 
tionary 322) and machine-level descriptors (dictionary 
326). 

[0068] The process of FIG. 5 is initiated when the ap- 
plication program 300 issues a database management 
request. For example, the request can be an SQL state- 
ment OPEN. This request results in a call 304 to the ap- 
plication manager 306. The receiver's application man- 
ager 306 first has to establish a connection with the de- 
sired database management system on the serving ma- 
chine. This is accomplished by constructing a RE- 
QUEST-CONNECTION command in accordance with 
FIG. 5, with parameter values which describe itself (ma- 
chine and code page designations) and the level of 
DBMS services desired (in this case, SQLAM3), as well 
as parameters (not shown) which identify the serving 
DBMS. This command is passed at 308 to the commu- 
nications agent 31 0 which is responsible for establishing 
the communication link with the identified serving ma- 
chine. The REQUEST-CONNECTION command is sent 
over a conventional communications link 312 to the 
communications agent 314 responsible for the other 
end of the communication channel. The agent 314 ex- 
amines the DBMS parameter (FIG. 5) to determine 
which level of server SQL application manager to in- 
voke. Once the determination and invocation is complet- 
ed, the agent 314 forwards at 316 the request to the' in- 
voked SQL application manager 318. The manager 318 
accesses at 320 the DBMS level dictionary 322 to obtain 
a descriptor which matches the receiver's desired level 
of function. (In the preferred implementation, the content 
of this descriptor is known early in the development cy- 
cle and for processing efficiency is "built into" the appli- 
cation manager 318.) Similarly, the manager 31 B ac- 
cesses at 324 the identified machine level descriptor 
from the dictionary 326. This includes descriptors 
matching the machine designated in the MACH param- 
eter of the REQUEST-CONNECTION command and a 
code page identified in the CODE PAGE parameter. 
[0069] Having verified that the receiver's environment 
can be handled, the application manager 31 8 constructs 
a COMPLETE-CONNECTION command as illustrated 
in FIG. 5. The command states the serving machine's 
characteristics in the MACH code page parameters and 
the level of system function which the serving machine 
will support in the DBMS parameter. It is contemplated 
in the invention that the connection steps may repeat in 
order to support negotiation to a different system level 
than that originally requested. Next, the COMPLETE- 
CONNECTION response is returned to the requesting 
machine 260 by sending it on 328 to the agent 31 4 which 
communicates it on the communication link 312 to the 
receiver agent 31 0. The receiver agent 31 0 sends the 
COMPLETE-CONNECTION command and parameters 
at 330 to tne application manager 306. In a manner sim- 
ilar to the manager 31 8, the manager 306 accesses the 
system and machine-level descriptors which describe 
the server machine and system characteristics from the 



dictionaries 342 and 346. Having validated that connec- 
tion has been established, and having obtained the ma- 
chine- and syst m-level descriptors at both ends of the 
connection, processing continues. The requester's ap- 

s plication manager 306 constructs a REQUEST-DATA 
command corresponding to the OPEN request from the 
application program 300. This may include an optimal 
input data descriptor and input data. This command is 
sent to the server's application manager 318 via 308, 

10 310, 312, 314 and 316. The application manager 318 
recognises a first request", processes any input data 
descriptor, converts any input data, and issues an 
OPEN command 332 to the local DBMS 334, which re- 
turns the status in the form of an SQL communication 

'5 area 336. Next, the manager 31 8 issues a request on 
332 to determine the format of the answer set. The 
DBMS 334 builds an SQL data area describing the rows 
which will be returned. This data area is returned on 336 
to the server application manager 31 8 which constructs 

so the user data descriptor for the data. Assuming that data 
is buffered into the manager 318 and that there is room 
in the buffer, the server's application manager 318 is- 
sues an SQL FETCH request on 332 to the DBMS 334 
which returns a first row of data on 336. (It is assumed 
that the data to be returned corresponds to the user data 
20 in FIGS. 1A and 4B.) Next, the server application 
manager 31 8 places the data in a reply buffer and issues 
a PROVIDE-DATA command to send the data to the re- 
quester's application manager 306 via 328, 314, 312, 

30 310, and 330. It is contemplated, but not required, that 
the server's application manager 318 may read ahead 
to fill buffers in anticipation of the next REQUEST-DATA 
command. 

[0070] Upon receiving data with the first PROVIDE- 
RS DATA command, the receiver's application manager 
306 processes the user data descriptor to verify correct- 
ness and to prepare to convert data subsequently re- 
ceived. Assuming no errors are found, the application 
manager 306 then sends the result of the OPEN back 
<0 to the application program 300 on 338. From now on, 
the receiver's application manager 306 may, but is not 
required to, read ahead requesting additional buffers 
from the server's application manager 318 in anticipa- 
tion of FETCH requests. 
45 [0071] Having successfully opened a Cursor, the ap- 
plication program 300 issues an SQL FETCH which is 
processed by the receiver's application manager 306. 
At this time, the receiver's application manager 306 has 
a row of data to return, and converts the data and returns 
so it on 338 to the application program 300. The application 
300 processes the data and SQL communication area 
received and subsequently issues another FETCH com- 
mand on 304 to obtain another row of data. The request- 
er's application manager 306 having no data to satisfy 
ss this request sends another REQUEST-DATA command 
to the server's application manager 318 via 308, 310, 
31 2, 31 4, and 31 6. The server's application manager 
31 8 having read ahead, has a buffer containing the last 
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two rows of data. These rows are sent with the PRO- 
VIDE -DATA command to the requestor's application 
manager 306 via 328, 314. 312, 310, and 330. The ap- 
plication manager 306 then converts the first row of the 
buffer using the previously constructed conversion da- s 
scriptors and passes it on 338 to the application 300. 
[0072] To complete the example, the application 300 
issues another SQL FETCH request on 304 to request 
the last row of the answer set. The receiver's application 
manager 306 converts this last row of data and returns '0 
it to the application. 

[0073] In this example, end-of-query is understood by 
the application by content of the result achieved. Addi- 
tional FETCH requests would be required as would an 
SQL communication area indicating end-of-query, »s 
which would have been constructed to allow the DBMS 
334 to signal this condition to the application. However, 
this is beyond the scope of this invention and is not dis- 
cussed. 

[0074] FIG. 7 illustrates the benefits of the invention 20 
in an alternative environment in which a requesting da- 
tabase machine requests data from a serving database 
machine through an intermediate database server/rout- 
er. For the purposes of this example, the intermediate 
server/router machine is not required to perform addi- 25 
tional database functions to satisfy the original request. 
Such function is not, however, precluded by this inven- 
tion. 

[0075] It is further assumed for this illustration that a 
connection has already been established (as illustrated 30 
in FIG. 5) between the requesting machine and the serv- 
er/router machine, and also between the server/router 
machine and the serving machine. 
[0076] In step 710, the requesting machine assem- 
bles a data request, sending a REQUEST-DATA com- 35 
mand 720, including (for this example) an input data de- 
scriptor and input data. In 730 the server/router machine 
receives the REQUEST-DATA with the input data de- 
scriptor and input data. The server/router machine de- 
termines that it does not need to do any processing of #> 
the input data for the request, and that the request is to 
be processed by the serving machine. The server/router 
machine, therefore, does not do any conversion of the 
input data. The server/router, ensuring that the active 
machine and system level descriptors correspond to the -*s 
requesting machine, forwards the REQUEST-DATA 
command with the input data descriptor and the input 
data (still in the native format of the requesting machine) 
to the serving machine for processing. 
[0077] In step 740, the serving machine receives the so 
REQUEST-DATA command, input data descriptor and 
input data, and calls the conversion process if neces- 
sary. 

[0078] Notice that, if the native format of the request- 
ing machine is the same as that of the serving machine, 55 
no conversion of the input data will be necessary even 
though the native format of the intermediate server/rout- 
er machine may be different. Also note that, if the native 



format of the requesting machin is different than that 
of the serving machine, only one conversion is per- 
formed (at the serving machine) even though the format 
of the intermedial server/router machine may be differ- 
ent from both the requesting and the serving machine. 
[0079] The serving machine accesses the local 
DBMS in order to build the user data description and 
obtain the user data. A PROVI DE-DATA command 750 
containing the user data descriptor, an SQLCA and the 
user data (in the serving machine's native format) is then 
sent to the server/router machine. 
[0080] The server/router machine recognises that it is 
not required to do any processing on the user data, and 
therefore does not do any conversion of the user data. 
The server/router 760 ensures that the active machine 
and system level descriptors correspond to the serving 
machine, and forwards the PROVI DE-DATA command 
with the user data descriptor arid user data (still in the 
native format of the serving machine) to the requesting 
machine. 

[0081] In 770, the requesting machine receives the 
PROVI DE-DATA command with the user data descrip- 
tor and user data, calls the conversion process if nec- 
essary, and returns the user data to the user. 
[0082] Again notice that, if the native format of the 
serving and requesting machines are the same, no con- 
version of the user data is performed, even if the native 
format of the intermediate server/router machine is dif- 
ferent. Also notice that if the native format of the serving 
and requesting machines are different, only one conver- 
sion of the user data (at the requesting machine) is per- 
formed even if the native format of the intermediate serv- 
er/router machine is different from both the serving and 
requesting machines. 

[0083] A data converter is not illustrated as an ele- 
ment in any of the figures, it being understood, that data 
format conversion is well-known in the art. For example, 
US -A- 4,559,614 describes in detail how conversion 
from a first to a second internal code format is accom- 
plished for data transmitted between twodissimilar com- 
puter systems. 



Claims 

1. A method for converting data transmitted between 
a first database management system and a second 
database management system, in a system includ- 
ing the first database management system for man- 
aging a database (40) including data having a first 
data format and the second database management 
system for managing a database (50) including data 
having a second data format, the method including 
the steps of: 

storing at the first database management sys- 
tem and at the second database management 
system respective sets of machine descriptors 
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describing machine data formats and system 
descriptors describing database language 
characteristics; 

establishing a communication link between the 
first and second database management sys- s 
terns, including each of said first and second 
database management systems sending to the 
other one of said first and second database 
management systems an identifier of its ma- 
chine and system descriptors, each of said io 
identifiers being in a canonical form under- 
standable by both database management sys- 
tems; 

sending from the first to the second database 
management system a command containing is 
data in a data format native to the first database 
management system; and 
converting, at the second database manage- 
ment system, data in the command sent from 
the first database management system utilising 20 
the machine descriptors and system descrip- 
tors identified by the first database manage- 
ment system. 

2. The method of claim 1 , further including: 25 

at the second database management system, 
processing the command to produce resulting 
data, the resulting data being in the data format 
native to the second database management 30 
system; 

sending the resulting data in the data format na- 
tive to the second database management sys- 
tem to the first database management system; 
and 35 
at the first database management system, con- 
verting the resulting data into the data format 
native to the first database management sys- 
tem utilising the machine descriptors and sys- 
tem descriptors identified by the second data- 40 
base management system. 

3. The method of claim 2, wherein the system further 
inciudes a first database system unit connected be- 
tween the first database management system and <s 
the second database management system, where- 
in: 

the step of sending the command includes re- 
ceiving the command at the first database system 
unit and sending the command from the first data- so 
base system unit to the second database manage- 
ment system without converting the data in the com- 
mand into a data format native to the first database 
system unit. 

55 

4. The method of Claim 3, wherein the system further 
includes a second database system unit connected 
between the first database management system 



and the second database management system, 
wherein: 

the step of sending the r suiting data includes 
receiving the resulting data at the second database 
system unit and sending the resulting data from the 
second database system unit to the first database 
management system without converting the data 
format of the return data into a data format native 
to the second database system unit. 

5. The method of Claim 2, wherein the first database 
management system is a first version of a database 
management system and the second database 
management system is a second version of the da- 
tabase management system, the first and second 
versions being non-identical. 

6. The method of Claim 2, wherein the first database 
management system is for executing on a first dig- 
ital computer which represents data in a first internal 
format and the second database management sys- 
tem is for executing on a second digital computer 
which represents data in a second internal format, 
the first and second internal formats being non- 
equivalent. 

7. A method for minimising conversion of data trans- 
ferred between database managers in a distributed 
database system including a plurality of database 
managers each for executing in a respective digital 
computer, the method comprising the steps of: 

storing in association with the first database 
manager and the second database manager 
respective sets of machine descriptors describ- 
ing machine data formats and system descrip- 
tors describing database language character- 
istics; 

establishing a communication link between a 
first digital computer and a second digital com- 
puter for executing, respectively, the first and 
second database managers; 
each of said first and second database manag- 
ers sending to the other one of said first and 
second database managers an identifier of its 
associated machine and system descriptors, 
each of said identifiers being in a canonical 
form understandable by both database manag- 
ers; 

sending a command containing input data from 
a first database manager to a second database 
manager, the input data having a data format 
used by the first database manager; 
at the second database manager, if the second 
database manager uses a data format which is 
non-equivalent to the data format used by the 
first database manager, converting the input 
data into the data format used by the second 
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database manager; 

at the second database manager, executing the 
command to produce resulting data in the data 
format used by the second database manager; 
sending the resulting data in the data format s 
used by the second database manager to the 
first database manager; and 
at the first database manager, if the data format 
used by the first database manager is not 
equivalent to the data format used by the sec- io 
ond database manager, converting the result- 
ing data into the data format used by the first 
database manager. 

8. A method for minimising the conversion of data '5 
" communicated between a user database manager 
which controls a first database and a server data- 
base manager which controls a second database, 
the method including the steps of: 

storing in association with the user database 
manager and the server database manager re- 
spective sets of machine descriptors describing 
machine data formats and system descriptors 
describing database language characteristics; 25 
establishing a communication link between the 
user database manager and the server data- 
base manager, including each of said user and 
server database managers sending to the other 
one of said user and server database manag- 30 
ers an identifier of its associated machine and 
system descriptors, each of said identifiers be- 
ing in a canonical form understandable by both 
database managers; 

sending from the user database manager to the 35 
server database manager a command contain- 
ing input data, the input data having a data for- 
mat native to the user database manager; 
at the server database manager, converting the 
input data into a data format native to the server *o 
database manager; 

at the server database manager, executing the 
command by processing the input data after 
converting the input data; 

in response to executing the command, obtain- 45 
ing resulting data from the second database, 
the resulting data having the data format native 
to the server database manager; 
sending the resulting data to the user first da- 
tabase manager; and SO 
at the user database manager, converting the 
resulting data into the format native to the user 
database manager. 



Pat ntanspruche 

1. Verfahren zur Umwandlung von Daten, die zwi- 



schen einem ersten Datenbankyerwaltungssystem 
und einem zweiten Datenbankverwattungssystem 
ubertragen werden, in einem System, welches das 
erste Datenbankverwattungssystem zur Verwal- 
tung einer Datenbank (40), die Daten beinhaltet, 
welche ein erstes Datenformat haben, und das 
zweite Datenbankverwattungssystem zur Verwal- 
tung einer Datenbank (50), die Daten beinhaltet, die 
ein zweites Datenformat haben, enthalt, wobei das 
Verfahren die folgenden Schritte einschlieBt: 

am ersten Datenbankverwattungssystem und 
am zweiten Datenbankverwaltungssystem 
Speichern von jeweiligen Gruppen von Maschi- 
nendeskriptoren, die Maschinendatenformate 
beschreiben, und von Systemdeskriptoren, die 
Datenbanksprachmerkmale beschreiben; 

Aufbauen einer Kommunikationsverbindung 
zwischen den ersten und den zweiten Daten- 
bankverwattungssystemen, wobei der Aufbau 
einschlieBt, dass jedes der ersten und der zwei- 
ten Datenbankverwattungssysteme dem ande- 
ren der ersten und der zweiten Datenbankver- 
wattungssysteme eine Kennung seiner Ma- 
schinen- und Systemdeskriptoren sendet, wo- 
bei jede der Kennungen eine kanontsche Form 
aufweist, die von beiden Datenbankverwal- 
tungssystemen verstanden wird; 

Senden eines Befehls von dem ersten Daten- 
bankverwattungssystem an das zweite Daten- 
bankverwattungssystem, der Daten in einem 
Datenformat enthalt, das dem ersten Daten- 
bankverwaltungssystem eigen ist; und 

an dem zweiten Datenbankverwaltungssystem 
Umwandeln von Daten in dem von dem ersten 
Datenbankverwaltungssystem gesandten Be- 
fehl, wobei die Maschinendeskriptoren und die 
Systemdeskriptoren verwendet werden, die 
von dem ersten Datenbankverwattungssystem 
gekennzeichnet wurden. 

Verfahren nach Anspruch 1, das des Weiteren fol- 
gende Schritte einschlieBt: 

Verarbeiten des Befehls an dem zweiten Da- 
tenbankverwaltungssystem, urn resultierende 
Daten zu erzeugen, wobei die resultierenden 
Daten das Datenformat haben, das dem zwei- 
ten Datenbankverwaltungssystem eigen ist; 

Senden der resultierenden Daten in dem Da- 
tenformat, das dem zweiten Datenbankverwal- 
tungssystem eigen ist, an das erste Daten- 
bankverwattungssystem; und 
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an dem ersten Datenbankverwaltungssystem 
Umwandeln der resultierenden Daten in das 
Datenformat, das dem ersten Datenbankver- 
waltungssystem eigen ist, wobei die Maschi- 
nendeskriptoren und die Systemdeskriptoren s 
verwendet werden, die von dem zweiten Da- 
tenbankverwaltungssystem gekennzeichnet 
wurden. 

3. Verfahren nach Anspruch 2, wobei das System des »o 
Weiteren eine erste Datenbanksystemeinheit ent- 
halt, die zwischen dem ersten Datenbankverwal- 
tungssystem und dem zweiten Datenbankverwal- 
tungssystem angeschlossen ist, wobei: 

der Schritt des Sendens des Befehls den Empfang is 
• des Befehls an der ersten Datenbanksystemeinheit 
und das Senden des Befehls von der ersten Daten- 
banksystemeinheit an das zweite Datenbankver- 
waltungssystem ohne Umwandlung der in dem Be- 
fehl enthaltenen Daten in ein Datenformat, das der 20 
ersten Datenbanksystemeinheit eigen ist, enthalt. 

4. Verfahren nach Anspruch 3, wobei das System des 
Weiteren eine zweite Datenbanksystemeinheit ent- 
halt, die zwischen dem ersten Datenbankverwal- 
tungssystem und dem zweiten Datenbankverwal- 
tungssystem angeschlossen ist, wobei: 
der Schritt des Sendens der resultierenden Daten 
den Empfang der resultierenden Daten an der zwei- 
ten Datenbanksystemeinheit und das Senden der 
resultierenden Daten von der zweiten Datenbank- 
systemeinheit an das erste Datenbankverwaltungs- 
system ohne Umwandlung des Datenformats der 
Ruckgabedaten in ein Datenformat, das der zwei- 
ten Datenbanksystemeinheit eigen ist, enthalt. 

5. Verfahren nach Anspruch 2, wobei das erste Daten- 
bankverwaltungssystem eine erste Version eines 
Datenbankverwaltungssystems und das zweite Da- 
tenbankverwaltungssystem eine zweite Version 10 
des Datenbankverwaltungssystems ist, wobei die 
erste und die zweite Version nicht identisch sind. 

6. Verfahren nach Anspruch 2, wobei das erste Daten- 
bankverwaltungssystem auf einem ersten digitalen 
Rechner ausgefuhrt werden soil, der Daten in ei- 
nem ersten internen Format darsteltt, und das zwei- 
te Datenbankverwaltungssystem auf einem zwei- 
ten digitalen Rechner ausgefuhrt werden soil, der 
Daten in einem zweiten internen Format darstellt, 
wobei das erste und das zweite interne Format un- 
gleich sind. 

7. Verfahren zur Minimierung der Umwandlung von 
Daten, die zwischen Datenbankverwaltungspro- ss 
grammen in einem verteilten Datenbanksystem 
ubertragen werden, das eine Vielzahl von Daten- 
bankverwaltungsprogrammen enthaft, von denen 



jedes in einem jeweiligen digitalen Rechner ausge- 
fuhrt werden soli, wobei das Verfahren die folgen- 
den Schritte umfasst: 

in Verbindung mit dem ersten Datenbankv r- 
waltungsprogramm und dem zweiten Daten- 
bankverwaltungsprogramm Speichem von je- 
weiligen Satzen von Maschinendeskriptoren, 
die Maschinendatenformate beschreiben, und 
von Systemdeskriptoren, die Datenbank- 
sprachmerkmale beschreiben; 

Aufbauen einer Kommunikationsverbindung 
zwischen einem ersten digitalen Rechner und 
einem zweiten digitalen Rechner, um das erste 
beziehungsweise das zweite Datenbankver- 
waltungsprogramm auszufuhren; 

wobei jedes der ersten und der zweiten Daten- 
bankverwaltungsprogramme an das andere 
der ersten und der zweiten Datenbankverwal- 
tungsprogramme eine Kennung seiner zuge- 
horigen Maschinen- und Systemdeskriptoren 
sendet, wobei jede der Kennungen eine kano- 



wenn das zweite Datenbankverwaltungspro- 
gramm ein Datenformat verwendet, das un- 
gleich dem von dem ersten Datenbankverwal- 
tungsprogramm verwendeten Datenformat ist, 
Umwandeln der Eingabedaten in das von dem 
zweiten Datenbankverwaltungsprogramm ver- 
wendeten Datenformat an dem zweiten Daten- 
bankverwaltungsprogramm; 



Senden der resultierenden Daten in dem von 
dem zweiten Datenbankverwaltungsprogramm 
verwendeten Datenformat an das erste Daten- 
bankverwaltungsprogramm; und 

wenn das von dem ersten Datenbankverwal- 
tungsprogramm verwendete Datenformat un- 



nische Form aufweist, die von beiden Daten- 
wird; 

Senden eines Befehls, der Eingabedaten ent- 
hatt, von einem ersten Datenbankverwaltungs- 
programm an ein zweites Datenbankverwal- 
tungsprogramm, wobei die Eingabedaten ein 
Datenformat haben, das von dem ersten Da- 
tenbankverwaltungsprogramm verwendet 



Ausfuhren des Befehls an dem zweiten Daten- 
bankverwaltungsprogramm, um resultierende 
Daten in dem Datenformat zu erzeugen, das 
von dem zweiten Datenbankverwaltungspro- 
gramm verwendet wird; 
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gleich dem von dem zweiten Datenbankverwal- 
tungsprogramm verwendeten Datenformat ist, 
Umwandeln der resultierenden Daten in das 
von dem ersten Datenbankverwaftungspro- 
gramm verwendeten Datenformat an dem er- s 
sten Datenbankverwaltungsprogramm. 

8. Verfahren zur Minimierung der Umwandlung von 
Daten, die zwischen einem Benutzer-Datenbank- 
verwaltungsprogramm, das eine erste Datenbank '0 
steuert, und einem Server-Datenbankverwaltungs- 
programm, das eine zweite Datenbank steuert, 
ubertragen werden, wobei das Verfahren die fol- 
genden Schritte enthalt: 

is 

in Verbindung mit dem Benutzer-Datenbank- 
verwaltungsprogramm und dem Server-Daten- 
bankverwaltungsprogramm Speichern von je- 
weiligen Satzen von Maschinendeskriptoren, 
die Maschinendatenformate beschreiben, und zo 
von Systemdeskriptoren, die Datenbank- 
sprachmerkmale beschreiben; 

Aufbauen einer Kommunikationsverbindung 
zwischen dem Benutzer-Datenbankverwal- 25 
tungsprogramm und dem Server-Datenbank- 
verwaltungsprogramm, wobei der Aufbau ein- 
schlieGt, dass jedes der Benutzer-Datenbank- 
verwaltungsprogramme und der Server-Daten- 
bankverwaltungsprogramme dem anderen der 30 
Benutzer-Datenbankverwaltungsprogramme 
und der Server-Datenbankverwaltungspro- 
gramme eine Kennung seiner zugehorigen Ma- 
schinen- und Systemdeskriptoren sendet, wo- 
bei jede der Kennungen eine kanonische Form 3S 
aufweist, die von beiden Datenbankverwal- 
tungsprogrammen verstanden wird; 

Senden eines Befehls, der Eingabedaten ent- 
halt, von dem Benutzer-Datenbankverwal- *o 
tungsprogramm an das Server-Datenbankver- 
waltungsprogramm, wobei die Eingabedaten 
ein Datenformat haben, das dem Benutzer-Da- 
tenbankverwaltungsprogramm eigen ist; 

45 

an dem Server-Datenbankverwaltungspro- 
gramm Umwandeln der Eingabedaten in ein 
Datenformat, das dem Server-Datenbankver- 
waltungsprogramm eigen ist; 

so 

Ausfuhren des Befehls an dem Server-Daten- 
bankverwaltungsprogramm, indem die Einga- 
bedaten verarbeitet werden, nachdem sie um- 
gewandelt worden sind; 

55 

als Antwort auf die Ausf uhrung des Befehls Ab- 
rufen der resuftierenden Daten aus der zweiten 
Datenbank, wobei die resultierenden Daten 



das Datenformat haben, das dem Server-Da- 
tenbankverwaltungsprogramm igen ist; 

Senden der resultierenden Dat n an das erste 

Benutzer-Datenbankverwaltungsprogramm; 

und 

am Benutzer-Datenbankverwattungspro- 
gramm Umwandeln der resultierenden Daten 
in das Datenformat, das dem Benutzer-Daten- 
bankverwaltungsprogramm eigen ist. 



Revendications 

1. Un precede de conversion de donnees transmises 
entre un premier systeme de gestion de base de 
donnees et un deuxieme systeme de gestion de ba- 
se de donnees, dans un systeme comprenant le 
premier systeme de gestion de base de donnees, 
pour gerer une base de donnees (40), comprenant 
des donnees ayant un premier format de donnees, 
et le deuxieme systeme de gestion de base de don- 
nees pour gerer une base de donnees (50) compre- 
nant des donnees ayant un deuxieme format de 
donnees, le precede comprenant les etapes con- 
sistant a : 

memoriser, sur le premier systeme de gestion 
de base de donnees et le deuxieme systeme 
de gestion de base de donnees, des jeux res- 
pectifs de descripteurs machine, decrivant des 
formats de donnees machine, et de descrip- 
teurs systeme, decrivant des caracteristiques 
de langage de base de donnees; 

etablir une liaison de communication entre le 
premier et le deuxieme systemes de gestion de 
base de donnees, comprenant renvoi, par cha- 
cun desdits premier et deuxieme systemes de 
gestion de base de donnees, vers I'autre des- 
dits premier et deuxieme systemes de gestion 
de base de donnees, d'un identificateur de ses 
descripteurs machine et systeme, chacun des- 
dits identificateurs 6tant presents sous une for- 
me canonique comprehensible par les deux 
systemes de gestion de base de donnees; 

emettre depuis le premier au deuxieme syste- 
me de gestion de base de donnees, une ins- 
truction contenant des donnees sous un format 
de donnes natif vis-a-vis du premier systeme 
de gestion de base de donnees; et 

convertir, au deuxieme systeme de gestion de 
base, les donnees, se trouvant dans I'instruc- 
tion et ayant ete emises depuis le premier sys- 
teme de gestion de base de donnees, par utili- 
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conversion du format de donnees des donnees de 
retour en un format de donnees natif vis-a-vis de la 
deuxieme unite de systems de base de donnees. 

Le procede selon la revendication 2, dans lequel le 
premier systems de gestion de base de donnees 
est une premiere version d'un systeme de gestion 
de base de donnees et le deuxieme systeme de 
gestion de base de donnees est une deuxieme ver- 
sion du systeme de gestion de base de donnees, 
les premiere et deuxieme versions etant non-iden- 



6. Procede selon la revendication 2, dans lequel le 
15 premier systeme de gestion de base de donnees 
est prevu pour etre execute sur un premier ordina- 
teur numerique, representant des donnees sous un 
premier format interne, et le deuxieme systeme de 
gestion de donnees est prevu pour execution sur 
20 un deuxieme ordinateur numerique, representant 
des donnees sous un deuxieme format interne, les 
premier et deuxieme formats internes etant non 
equivalents. 

25 7. Un procede pour minimiser la conversion de don- 
nees transferees entre des gestionnaires de base 
de donnees dans un systeme de base de donnees 
distribue, incluant une plurality de gestionnaires de 
base de donnees, chacun prevu pour execution 
30 dans un ordinateur numerique respectif, le procede 
comprenant les etapes consistant a : 

stocker, en association avec le premier gestion- 
naire de base de donnees et le deuxieme ges- 
3S tionnaire de donnees, des jeux respectifs de 

descripteurs machine decrivant des formats de 
donnees machine et des descripteurs systeme 
decrivant des caracteristiques de langage de 
base de donnees; 

40 

etablir une liaison de communication entre un 
premier ordinateur numerique et un deuxieme 
ordinateur numerique, pour executor, respecti- 
vement, les premier et deuxieme gestionnaires 
« de base de donnees; 



sation des descripteurs machine et des des- 
cripteurs systeme ayant ete identifies par le 
premier systeme de gestion d bas de don- 
nees. 

2. Le procede selon la revendication 1 , comprenant 
en outre : 

au deuxieme systeme de gestion de base de 
donnees, le traitement de Pinstruction pourpro- 
duire des donnees resultantes, les donnees re- 
sultantes se presentant sous le format de don- 
nees natif vis-a-vis du deuxieme de gestion de 
base de donnees; 

envoyer les donnees resultantes, sous le for- 
mat de donnees natif vis-a-vis du deuxieme 
systeme de gestion de base de donnees, au 
premier systeme de gestion de base de don- 
nees; et 

au deuxieme systeme de gestion de base de 
donnees, convertir les donnees resultantes au 
format de donnees natif vis-a-vis du premier 
systeme de gestion de base de donnees, par 
utilisation des descripteurs machine et des des- 
cripteurs systeme ayant ete identifies par le 
deuxieme systeme de gestion de base de don- 
nees. 

3. Le procede selon la revendication 2, dans lequel le 
systeme comprend en outre une premiere unite de 
systeme de base de donnees, connectee entre le 
premier systeme de gestion de base de donnees et 
le deuxieme systeme de gestion de base de don- 
nees, dans lequel : 

I'etape d'envoi de ('instruction comprend la recep- 
tion de I'instruction a la premiere unite de systeme 
de base de donnees, et renvoi de I'instruction de la 
premiere unite de systeme de base de donnees au 
deuxieme systeme de gestion de base de donnees, 
sans proceder a la conversion des donnees, se 
trouvant dans I'instruction, en un format de donnees 
qui soil natif vis-a-vis de la premiere unite de sys- 
teme de base de donnees. 

4. Le procede selon la revendication 3, dans lequel le 
systeme comprend en outre une deuxieme unite de 
systeme de base de donnees, connectee entre le 
premier systeme de gestion de base de donnees et so 
le deuxieme systeme de gestion de base de don- 
nees, dans lequel : 

I'etape d'envoi des donnees resultantes comprend 
la reception des donnees resultantes sur la deuxie- 
me unite de systeme de base de donnees, et renvoi ss 
ties donnees resultantes de la deuxieme unite de 
systeme de base de donnees au premier systeme 
de gestion de base de donnees, sans proceder a la 



chacun desdits premier et deuxieme gestion- 
naires de base de donnees envoyant, a I'autre 
parmi lesdits premier et deuxieme gestionnai- 
res de base de donnees, un identificateur de 
ses descripteurs machines et systemes asso- 
cies, chacun desdits identificateurs se presen- 
tant sous une forme canonique, comprehensi- 
ble par les deux gestionnaires de base de don- 
nees; 

envoyer une instruction comprenant des don- 
nes d'entree, depuis un premier gestionnaire 
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de base de donnees a un deuxieme gestionnai- 
re de base de donnees, les donnees d'entree 
ayant un format de donnees utilise par le pre- 
mier gestionnaire de base de donnees; 

5 

au deuxieme gestionnaire de base de donnees, 
si le deuxieme gestionnaire de base de don- 
nees fait utilisation d'un format de donnees qui 
n'est pas equivalent au format de donnees qui 
est utilise par le premier gestionnaire de base io 
de donnees, convertir les donnees d'entr6e au 
format de donnees utilise par le deuxieme ges- 
tionnaire de base de donnees; 

au deuxieme gestionnaire de base de donnees, 15 
executer Instruction pour produire des don- 
nees resultantes au format de donnees utilise 
par le deuxieme gestionnaire de base de don- 
nees; 

20 

envoyer les donnees resultantes, au format de 
donnees utilise par le deuxieme gestionnaire 
de base de donnees, au premier gestionnaire 
de base de donnees; et 

25 

au premier gestionnaire de base de donnees, 
si le format de donnees utilise par le premier 
gestionnaire de base de donnees n'est pas 
equivalent au format de donnees utilise par le 
deuxieme gestionnaire de base de donnees, 30 
convertir les donnees resultantes au format de 
donnees qui est utilise par le premier gestion- 
naire de base de donnees. 

Un procede pour minimiser la conversion des don- 35 
nees communiquees entre un gestionnaire de base 
de donnees utilisateur controlant une premiere ba- 
se de donnees et un gestionnaire de base de don- 
nees serveur controlant une deuxieme base de 
donnSes, le procede comprenant les etapes con- *o 
sistant a: 

memoriser, en association avec le gestionnaire 
de base de donnees utilisateur et le gestionnai- 
re de base de donnes serveur, des jeux respec- « 
tif s de descripteurs machine, decrivant des for- 
mat de donnees machine et des descripteurs 
systeme decrivant des caracteristiques de Ian- 
gage de base de donnees; 

so 

etablir une liaison de communication entre le 
gestionnaire de base de donnees utilisateur et 
le gestionnaire de base de donnees serveur, y 
compris renvoi, par chacun desdits gestionnai- 
res de base de donnees utilisateur et serveur, ss 
a I'autre desdits gestionnaires de base de don- 
nees utilisateur et serveur, d'un identificateur 
de ses descripteurs machine et systeme asso- 



cies, chacun desdits identificateurs se presen- 
tant sous forme canonique, comprehensible 
par les deux gestionnaires de base de don- 
nees; 

envoyer, depuis le gestionnaire de base de 
donnees utilisateur au gestionnaire de base de 
donnees serveur, une instruction contenant 
des donnees d'entree. les donnees d'entree 
ayant un format de donnees natif vis-a-vis du 
gestionnaire de base de donnees utilisateur; 

au gestionnaire de base de donnees serveur, 
convertir les donnees d'entree en un format de 
donnees natif vis-a-vis du gestionnaire de base 
de donnees serveur; 

au gestionnaire de base de donnees serveur, 
executer I'instruction, par traitement des don- 
nees d'entree apres conversion des donnees 
d'entree; 

en reponse a I'execution d'instruction, obtenir 
des donnees resultantes depuis la deuxieme 
base de donnees, les donnees resultantes 
ayant le format de donnees natif vis-a-vis du 
gestionnaire de base de donnees serveur; 

envoyer les donnees resultantes au premier 
gestionnaire de base de donndes utilisateur; et 

au niveau du gestionnaire de base de donnees 
utilisateur, convertir les donnees resultantes au 
format de motif vis-a-vis du gestionnaire de ba- 
se de donnees utilisateur. 
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